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Amendments to the Specification 

Please replace the paragraph at page 4, lines 7 through 21 with the following amended 
paragraph: 

Referring to Fig. 1, in a computer network 10, such as a network using the TCP/IP 
protocol, a logical connection is maintained between a local node or user 12 and a remote node 
30. The user node 12 may, for example be a personal computer (PC) and the remote node 30 
may be a file server such as a web server. Data is carried between the user 12 and the remote 
node 30 by transmitting data in formatted packets, which flow in a stream over the connection. 
The connection includes both wired links 20, 24 and a wireless link 26. The wireless link 26 is 
maintained by a base station processor 16 and a subscriber access unit 14, which is in turn 
connected to the user 12. The base station processor 16 connects to a public access network such 
as the Internet 28 via an internetworking gateway 1 8 over the wired link 24. A user 12 can 
therefore maintain wireless connectivity to a remote node 30 via the wireless link 26 provided by 
the base station processor 16 and the subscriber access unit 14. The connection between the 
remote node 30 and the user 12 conforms to a protocol, such as TCP/IP. As described above, 
TCP/IP was developed for wired networks, and, accordingly, does not lend itself directly to 
efficient transmissions over the wireless link 26. 

Please replace the paragraph at page 5, lines 14 through 28 and page 6, lines 1 through 2 
with the following amended paragraph: 

Referring to Fig. 3, the flow model table 34 is shown having flow model entries 34a, 34b, 
[[and]] 34c ,... 34n . As described above, each flow model entry 34n defines link performance 
metrics 32 corresponding to the data type of a particular stream of packets. In one embodiment, 
a packet based network associates ports with applications. By examining the port associated 
with a transmitted packet, the application type can be determined. For example, in a TCP/IP 
network, certain well known port numbers 48 are predetermined and identified by RFC 1700 
promulgated by the Internet Engineering Task Force (IETF). The flow model entry 34n 
corresponding to the well known port number 48 determines the application type 50. The 
application type 50 is indicative of the loss tolerance of the stream. For example, flow model 
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entry 34c indicates a streaming audio data type. Streaming audio is generally thought to be more 
loss-tolerant because lost or erroneous packets would merely be heard as a slight pop or glitch in 
the output audio signal heard by the user. On the other hand, flow model entry 34b corresponds 
to a file transfer, and accordingly, is not tolerant to lost or erroneous packets. The use of the port 
number as a link performance characteristic as defined herein is exemplary. Other performance 
characteristics, such as those defined in the flow model table 34 and others, could be employed 
in computing the transfer model. 

Please replace the paragraph at page 6, lines 3 through 1 1 with the following amended 
paragraph: 

Referring to Fig. 3, 4, and 5b, the selected flow model 34n is read to determine the 
corresponding transfer model index 52, as depicted at stepl 18. The transfer model index 52 is 
invoked to determine a transfer model entry [[54n]] 54a, 54b, 54c, ...or 54n in the flow model 
table 42, and the corresponding link control parameters 46 are retrieved, as shown at step 120. 
Other computations may also be employed to determine link control parameters, in addition to 
the transfer model table 42 lookup described above. Packet transmission employing the link 
control parameters 46 is requested, as disclosed at step 122, by applying the link control 
parameters 46 to the connection. 

Please replace the paragraph at page 9, lines 8 through 29 and page 10, lines 1 through 13 
with the following amended paragraph: 

Referring to Fig. 7, at the base station 16, incoming traffic is separated into individual 
traffic flows destined for separate subscriber access units 14 generally (Fig. 1). The traffic flows 
may be separated by various methods, such as by examining a destination address field in the 
TCP/IP header. The individual traffic flows are delivered first to transport modules 401-1, 401- 
2, . . ., 401-n with a transport module 401 corresponding to each of the intended subscriber units 
14. A given transport module 401 is the first step in a chain of processing steps that is performed 
on the data intended for each subscriber unit 14. This processing chain includes not only the 
functionality implemented by the transport module 401 but also a number of session queues 410, 
a session multiplexer 420, and transmission buffers 440. The outputs of the various transmission 
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buffers 440-1 , 440-2, . . . , 440-n are then assembled by a transmit processor 450 that formats the 
data for transmission over the forward radio links [[110]]. 

Returning attention now to the top of the Fig. 7 again, each transport module 401 has the 
responsibility of either monitoring the traffic flow in such a way that it stores data belonging to 
different transport layer sessions in specific ones of the session queues 410 associated with that 
transport module 401 . For example, transport module 401-1 assigned to handle data intended to 
be routed to subscriber unit [[101-1]] 14 has associated with it a number, m, of session queues 
410-1-1, 410-1-2, 4 10-1 -m. In the preferred embodiment, a given session may be 
characterized by a particular transport protocol in use. For example, in a session oriented 
transport protocol, a session queue 410 is assigned to each session. Such session transport 
oriented protocols include, for example, Transmission Control Protocol. In sessionless transport 
protocols, a session queue 410 is preferably assigned to each stream. Such sessionless protocols 
may for example be the Universal Datagram Protocol (UDP). Thus traffic destined for a 
particular subscriber unit 14 is not simply routed to the subscriber unit 14. First, traffic of 
different types from the perspective of the transport layer are first routed to individual session 
queues 4 1 0- 1 - 1 , 4 1 0- 1 -2, . . . , 4 1 0- 1 -m, associated with that particular connection. In accordance 
with the system as defined above, traffic indicating a new connection is analyzed to determine 
link performance characteristics 44 for the messages received on that connection. The link 
performance characteristics 44 are analyzed to determine a flow model index 55, as described 
above with respect to Fig. 3. The flow model is then used to compute a transfer model entry 54 
as described above with respect to Fig. 4. The transport module 401 invokes the link 
performance characteristics 46 corresponding to the computed transfer model entry 54, and 
applies them to the session queue 410-n-m for this connection. 



